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(57) ABSTRACT 

An object oriented software environment permits, through 
declarative programming techniques, customization of func- 
tionality of an object. The object oriented software environ- 
ment includes a plurality of objects, wherein each object 
contains at least one method. A user of the object oriented 
software environment submits one or more declarative state- 
ments to augment the functionality of a method on an object. 
In response, the object oriented software environment asso- 
ciates the declarative statements to the method identified on 
the object such that when the method on the object is called, 
the declarative statements, associated with the object, are 
executed in addition to the methods on the object. The 
declarative programming technique permits augmenting the 
functionality of a method on an object with "rules." In 
addition, two or more methods may be associated together 
to generate an event that propagates from one method to 
another method. The programming techniques disclosed 
also permit integration of declarative, compiled and script- 
ing approaches to integrate three styles of applications 
program development. 
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METHODS AND APPARATUS FOR cated in the child type. Instead, the interfaces and imple- 

DECLARATIVE PROGRAMMING mentations may be incorporated in any child type through 

TECHNIQUES IN AN OBJECT ORIENTED reference of the parent or base type. 

ENVIRONMENT Just as there are many different concepts that define object 

5 oriented programming, there are also many different and 
BACKGROUND OF THE INVENTION diverse object oriented systems. One example of how object 
1 Field of the Invention oriented systems differ is in methods of code reuse. 
The present invention is directed toward the field of object . ^ discusied above, object oriented programming tech- 
oriented programming, and more specificaUy to methods, jo !"q"espermit code reuse through reuse of objects. However, 
apparatus, and computer readable medium for enhancing '^"l*"' circumstances, a programmer may desire to alter 

declarative programming in an object-oriented system. f° ^'"^'"l^ °*'J«'=' ^"^-u' ""jing ^° ^''^"^^y "^ject. 

Instead of creating a new and distmct object, current object 
I. Art background oriented programming techniques permit a program devel- 
An object oriented approach to programming provides oper to "subclass" the object. Generally, subclassing tech- 
many advantages over traditional procedural programming is jjjqyes permit a developer to generate a new method on a 
approaches. For example, an object oriented approach per- subclass, such that the new subclass has a method different 
mits code reuse through inheritance and modularity through from a method in the original class. Redirecting a call from 
encapsulation. There are many views as to what concepts an old method of a class to a new method in a subclass is 
define object oriented programming, and there are many known as method overriding. 

terms and definitions for defining these concepts. In general, 20 j^^^^^^ interfaces include a plurality of pointers 

objects mcorporate procedures, also called methods or ^^^^ ^^^^^ ^ ^.^le of pointers, known as a virtual table 

operations, and data, also caUed attributes or properties. (v_table.) In general, subclassing techniques involve chang- 

Objects are instantiated from and described by structures ^ j^e pointer in an object's v_table to point to a new 

known as classes or types. For purposes of nomenclature, ^^^^-^^ ^^^^^^ ^^^^ j^e method on that object is 

the object onented programming environment described 25 ^^^^^^^ ^^^^^^^ ^.^^^^ ^^^^ ^^^^.^^ 

herein defines classes as types. A type is a general abstract ^^^^^^^ implement subclassing, a program developer 

specification, and an object instantiated from a type is a ^^^^-^^^ ^^^^^ ^^^^^^^^ ^^^.^y 

specific concrete instance of the type. object's v_table. However, a software developer does not 

A type consists of an interface and an implementation. always have access to an object's metadata. For example, if 

The interface comprises variables and function declarations, the software developer is using an object that consists of 

wherein the variables represent the attributes of the type, and C++ compiled code, then the developer does not have access 

the function declarations specify methods for manipulating to the object's v_table, and the subclassing technique is not 

those attributes as well as performing other operations. The available to augment or change the methods on the object, 

declaration specifies the name, return type, and argument, xhe software developer also requires knowledge of the 

known collectively as the signamre. The implementation signatures of all of the methods on the object. The location 

refers to the actual code that implements the methods of the v_lable is compiler dependent, and thus is not readily 

specified in the interface. Types may consist of abstract known from objects compiled from different compilers. In 

types or implementation types. Objects are not instantiated addition, to alter the v__table, the software developer 

from abstract types. Instead, objects are instantiated from an ^ requires knowledge of the location of the object's v_table. 

implementation type. Furthermore, the subclassing technique requires 

In general, objects communicate through message passing re-compiling the code, which in turn requires shutting down 

mechanisms. An object, known as a client object, may call the application and reloading both the new and old code, 

a method of another object. A client object invokes a method Thus, it is desirable to provide a technique to permit 

of another object by accessing the object via the defined augmentationof a method, to alter the behavior of an object, 

interfaces. Thus, to invoke a method in an object or to query even though the source metadata is not available to the 

an object, the client object requires knowledge of the sig- software developer, 

natures of the methods in the interface of the target object. There are various ways to approach application program 

The client object calls the methods and passes the appro- development in an object oriented programming environ- 

priate parameters. For example, to obtain the value of an menl, A declarative approach permits an application devel- 

attribute in an object, a client object calls a method, via an oper to express declarations by coding these declarations 

interface, to obtain the value. into the system. Although the declarative approach works 

'Ilie concept of isolating the implementation of the meth- best for certain tasks, such as adding features to an existing 

ods and attributes within an object is known as encapsula- system, some functions cannot be expressed in a declarative 

tion. Encapsulation is a powerful feature of object oriented 55 manner. 

systems because it separates the external part of an object Other systems permit application development through 
(e.g., the part exposed to the objects user) from the internal traditional code development cycles. For example, program- 
part (e.g., the structure and implementation). Therefore, ming languages, such as third generation languages (3GL), 
encapsulation permits changing the object implementation may be used to specify functionality through development of 
without affecting the interaction with other functions or 59 class objects. This approach to application development 
objects as long as the interface does not change. requires compiling code to generate executable run time 
Object oriented languages, such as the C++ programming code. Although the 3GL compiled approach is perhaps the 
language, permit the creation of special types via inherit- most powerful approach, it is also the most resource inten- 
ance. In general, inheritance is a mechanism for passing sive and time consuming approach, 
attributes and methods from a parent or base type to one or 65 A third approach to application development in an object 
more child or derived types. Inheritance permits code reuse oriented system is through use of fourth generation lan- 
because interfaces and implementations need not be duph- guages (4GL). The 4GL approach permits adding function - 
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ality to currently existing systems. Although each approach oriented software environment associates the declarative 
has benefits, it is desirable to permit integration of all three statements to the method identified on the object such that 
styles of application building. when the method on the object is called, the declarative 
To support application program development, a number statements, associated with the object, are executed in 
of tools and editors are used. One such tool permits dia- ^ addition to the methods on the object. The declarative 
gramming events to model an application program. programming technique permits augmenting the functional- 
Although these diagrammers provide a starting point for i^y of ^ method on an object with "rules." In addition, two 
code development, they do not adequately capture how or more methods may be associated together to generate an 
objects are afi[ected as the objects progress through the ^^ent that propagates from one method to another method, 
system. The modeling tools do not describe the structure and ^0 In one embodiment, the rules may be either "before" 
behavior of the objects. For example, prior art systems rules, which are executed prior to execution of the associated 
capture information about the system so that the user may method, or "after" rules, which are executed subsequent to 
query to determine the relationship between objects, and the associated method. The declarative programming tech- 
how these objects move through the system. Although these niques permit augmentation of methods both on the type 
queries are informative, they do not provide a means to ^5 system level and on the instance level. Thus, the user is 
enforce, through declarations, this relational information. permitted to associate declarative statements to a method on 
Therefore, it is desirable to provide an object oriented a specific instance of the object, or associate declarative 
system that enforces declarations to effect the relationships statements to a method on all instances of the object, 
among objects in the system. l^e programming techniques of the present invention also 

permit integration of declarative, compiled and scripting 

BRIEF DESCRIPTION OF THE DRAWINGS approaches for developing application programs in an objecl 

FIG. 1 illustrates one embodiment for implementing rules oriented environment. An abstract specification for an 

with an object. extended definition type system, which includes members to 

no, 2 is a flow diagram mustrating one embodiment for „ enforce rules through the type system, is implemented, 

a program flow that implements rules. Declarative rules which mipleraent functionality for appb- 

V, ° ^ .„ . . . cations program development, are enforced as rules m the 

HG. 3 Illustrates an abstract representation of event ^yp^ ^y^^.^^ Complied code, developed from an object 

propagation xn the type system. ^^^^^^^ language and compiled to include the extended 

FIG. 4 illustrates an example state model for a sales order definitions for the type system, operates in conjunction with 

application. 30 declarative rules. Scripts, developed from a fourth gen- 

FIG. 5 illustrates state models for the example order entry eration language (4GL), which specify additional function- 

and accounts receivable apphcations as well as their linking ality for applications program development, are also inte- 

through events. grated so that the scripts are enforced as rules in the type 

FIG. 6 illustrates a simplified state model consisting of a system. 

"New Order** state, an "Approved Stale", a "Place Order" DETAILED DESCRIPTION OF THE 

state, and a "Filled Order" state. PREFERRED EMBODIMENTS 

FIG. 7 illustrates adding a rule to the order entry state 

model of FIG. 6 to implement the specialized case of a rush An Overview of Rules 

order. 4q Jn general, rules are high level reqmrements or functions 

FIG. 8 is a block diagram illustrating program modules that augment the functionality of methods of an object. In 

for implementing rules of the present invention. one embodiment, rules are declarative techniques, that set 

FIG. 9 is a block diagram illustrating a pluraHty of bit forth requirements or parameters that define object behavior, 

maps for use with one embodiment of the optimization As is described more fully below, the rules of the present 

thunk. 45 invention may be implemented with different editors and 

HG. 10 is a flow diagram illustrating one embodiment for including editors and tools that are not designed to 

implementing rules. operative cooperatively (e.g., editors and tools that are not 

1,^ . . . , . .. . , generally compatible to operate with different type systems). 

HG. 11 is a block diagram illustrating an object onented ^j^g ^e added to objects of an applications 

development environment that mcorporates the techmques ^^^.^^^ even though the underlying method is compiled, 

of the present invenUon. jjie source metadata for the underlying object is not 

FIG. 12 is a flow diagram illustrating one embodiment for available, 

installing a rule. pIQ j illustrates one embodiment for implementing rules 

FIG. 13 illustrates a high level block diagram of a general with an object. An object interface 100 includes, in part, a 

purpose computer system in which the object oriented ss plurality of operations, labeled operationj, operation^, 

development system of the present invention may be imple- operationg . . . operation^. For purposes of nomenclature, an 

mented. operation as used herein describes a "slot" in a virtual table 

("v_table"). Unlike a method, an operation does not con- 
note a specific implementation. As shown in FIG. 1, each 

Declarative programming techniques in an object oriented 60 operation on the object interface 100 has a corresponding list 

software environment permit customizing functionality of of "before rules" 120. Also shown in FIG. 1 is a plurality of 

an object. The object oriented software environment actual methods 130. The actual methods 130 represent the 

includes a plurality of objects, wherein each object contains original implementation of the object prior to augmentation 

at least one method. The user of the object oriented software by the rules of the present invention. A decision block 110 

environment, such as an applications developer, submits one 65 directs the thread of execution of the program from an 

or more declarative statements to augment the functionality operation on the object interface 100 to either the corre- 

of at least one method of an object. In response, the object sponding list of before rules 120 or the actual method 130. 
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A list of "after rules" 140 corresponds to each of the actual 
methods 130 as indicated by the lines on FIG. 1. The after 
rules 140 includes a list of one or more rules for execution 
subsequent to execution of the corresponding actual method 
130. Similar to the before rules 120, the actual methods 130 5 
are shown coupled to the after rules 140 via decision blocks 
110. The decision blocks 110 indicate whether the thread of 
execution of a program is directed from the actual methods 
130 to the after rules 140, or whether the thread of execution 
returns directly to return to the caller (e.g., the caller that 
invoked the operation on the object interface 100). 

FIG. 2 is a flow diagram illustrating one embodiment for 
a program flow that implements rules. The calling code (e.g., 
the caller) initiates the flow through calling an operation 
identified on an object interface as shown in block 200. In 
response to the call, the thread of execution for the program 
flow jumps to an operation "pinch-point." In one 
embodiment, the pinch -point operation is implemented effi- 
ciently with a thunk, as explained more fully below. The 
pinch-point operation determines whether there are any rules 
associated with the corresponding operation as illustrated by 20 
block 220, If rules exist for the corresponding operation, the 
"outer" shell is entered and a determination/execution of 
before rules is made. The implementation method is called 
as shown in block 230. As shown in block 235, the after rules 
determination/execution is made in the outer shell. To exit 25 
the outer shell, a closure method is called as shown in block 
250. Alternatively, if there are no rules for the corresponding 
operation, the program flow jumps to caU the implementa- 
tion method (block 250.) 

The rules of the present invention have many applications 3Q 
in software programs to add or alter the functionality of an 
object. One application for rules is to define the range of 
parameters acceptable for execution of a method on an 
object. For example, a "time" method may utilize, as a 
parameter, a day of a month (e.g., day attribute). A rule, 35 
implemented as a before rule for the time method, checks 
whether the value stored in the "day" attribute is a valid day 
for the corresponding "month" parameter (e.g., the day 
parameter is a value between 1 and 30 for the month of 
September). 4q 

The rules of the present invention have appHcation to 
implement conditions or requirements prior to execution of 
methods on an object. This application of rules permits a 
user to set certain requirements prior to invocation of the 
method (e.g., a method). For example, in an order entry 45 
application program, the user may specify the requirement 
that before the "ship" method is executed, the shipping 
information, used by the ship method, must exist. 

The rules of the present invention may also operate in 
conjunction with states and state models. State models, 50 
defined to model the behavior of an applications program, 
transition from one state to another state based on conditions 
and events that occur during the execution of the application 
program. For an object oriented system that utilizes state 
models, rules may be used in conjunction with state models. 55 
In general, state rules determine and enforce state conditions 
before and after execution of a rule, as well as enforce 
transition from one state to another state. Another appHca- 
tion for rules for use in state models is to determine that an 
object is in a proper state prior to invocation of the associ- 60 
ated method. For example, a rule may check that an object 
is in a proper state prior to calling a method. If it is not, the 
rule may execute an error routine, such as displaying infor- 
mation on the output display to indicate the nature of the 
error. 65 

Rules also have application to implement help or instruc- 
tional messages in software programs. For example, a before 
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rule may be executed to display, in a dialog box, a help 
message that provides instructions to walk the user through 
the applications program prior to executing the actual 
method. 

Rules have further application to relate prior methods, and 
their results, to actual methods of the operation called. For 
example, a rule may declare that no method, previously 
executed, may fail, or else an error is generated. 

The after rules have application to add functionality based 
on the outcome of the actual method. For example, if a 
parameter, as a result of executing the actual method, is set 
to a value within a predetermined range, then the rule 
executes an action. The before rules of the present invention 
may be used for error recovery. For example, if a method 
requires a specific range of values for a parameter, one or 
more before rules may check to determine if the values of 
the parameters are within the range, and if not, truncate the 
values for subsequent execution of the method. As an error 
recovery technique, a before rule may also display a dialog 
box to request new parameter values within the required 
range. 

The declarative statement of a rule may be expressed in 
any form. In one embodiment, rules are expressed using the 
basic programming language. The declarative statement 
may call a difl"erenl routine or method depending upon the 
output of the actual method associated with the rule. For 
example, to implement an after rule that calls a routine based 
on a parameter value, the rule may set forth: 

If Attribute A^X, then call method Y. Similarly, several 
conditions may be linked together throu^ logical 
operands (e.g., AND, OR, XOR, NOR, etc.). 
In addition to parameter validation, rules may enforce 
conditions that check and enforce certain conditions 
including, cardinality, mandatory presence of a parameter, 
inclusive (e.g. one must have a value), exclusive (e.g., only 
one must have a value). Derivation rules are of the type that 
support attribute dependency chaining, generating default 
values, etc. 

Modehng y^proach To Applications Program 
Development 

In one embodiment, the type system for the object ori- 
ented development environment permits the use of state 
models. The behavior of an object may be specified through 
one or more state models. Within an object, a condition, 
which is identified by an application developer, controls the 
logical progression of the application. These conditions, 
which control the progression of the application, are called 
"states," Each state is provided with a fist of one or more 
valid predecessor and successor states. For example, a "sales 
order" object, developed for a sales order entry application, 
may include state declarations that an instance of the object 
must pass through an "approved state" before reaching a 
"shipped state." In addition, the states are specified with 
conditions to be observed and events to be raised when a 
transition from one state to another is proposed. 

In general, rules support the declarative style of applica- 
tion development. Specifically, rules permit an appHcation 
developer to specify declarations about the function of the 
system, and the system enforces these declarations on the 
type system level. Rules, if they are linked to states, can be 
turned on and off. There are many triggers that may invoke 
enforcement of a rule. For example, triggers may include 
receiving an event, calHng a method, entering or leaving a 
state, moving through a state transition, and changing and/or 
assessing an attribute of an object. 
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For each rule, a trigger invokes the rule, a conditioD "ship order*' event by calling a "ship order" method. For 

determines a course of action, and an action implements or purposes of nomenclature, the process of raising and 

enforces the rule. An example rule may be triggered when a responding to events is entitled "event propagation." Event 

method is called. For this exaimple rule, the condition may propagatioa begins with a source object raising an event, and 
be based on the state of an attribute in the called method's 5 it ends with a method being called on the sink object. One 

object. Based on the condition (e.g., the state of the or more sink objects register or subscribe to a source object's 

attribute), an action is executed such as returning an error or event. In addition, event signatures or categories may be 

an exception. An action may also include changing the state dynamically added at run time. Sink objects may register 

for a state model. interest in event signatures even if the som"ce object does not 

For purposes of nomenclature, an event is a notification or currently export the event (e.g., in a programming 

an announcement firom an object. Events are a special case environment, the source can raise events dynamically with- 

of rules. Objects register or subscribe to events in order to out prior notice of their existence). Consequently, events 

receive the event notification upon occurrence of the sped- form a one to many relationship among the events source 

fied event. Unlike an attribute, an event communicates to object, the type of event, and the event sink, 
other objects that something has occurred. An event is not a An event transformer is an object that is logically situated 

method call, but methods may be invoked as a result of the between a source object and a sink object. The purposes of 

occurrence of an event. A method call invokes a one to one an event transformer are to perform impedance matching 

relationship between the caller and the method. In contrast, between the source and sink objects and to perform calcu- 

with events, there is a one to many relationship between the Ution and event flow. In general, event propagation relies on 

object that raises the event and the objects that receive the the fact that the sink object implements the exact event 

event. signature. For example, if an event signature is specified 

In certain circumstances, a single user action may pre- with two parameters, then the source object passes two 

cipitate the firing of a sequence of related events. While the parameters and all of the sink objects are implemented with 

object is in the process of firing this sequence of events, the the two parameters. If the sink object does not implement the 
object relinquishes the thread of execution to event handlers ^5 exact signature required by the source object, then an event 

which, may in turn, attempt to set properties and call transformer is required to provide matching of signatures, 

methods on the object that is the source object of the event. The event transformers then receive the event on behalf of 

Because of this, an object may enter a special state that the sink object, perform some rearrangement or calculation 

disallows some subset of normally permissible activities on of the event information, and then redispatch the event to the 

the source object. Objects are required to handle reentrant sink object. 

situations, but they are not required to be arbitrarily func- FIG. 3 illustrates an abstract representation of event 

tional when reentered. For example, while firing a request propagation in the type system, A plurality of sink objects, 

event, it may be illegal to call a method on the object which labeled sink object^, sink object^, and sink object^, subscribe 

would itself fire the request event. The limitation to disallow to an event, such as eventj. The source object, upon occur- 
certain functions is up to the object, but user written code ^5 re nee of the specified trigger, generates the event^ notifica- 

may attempt implausible actions on the object. tion for the event transformer objects. In turn, the event 

As discussed above, an event is a notification or transformer objects relays the events to the sink objects, 
announcement made by an object. Like a method, an event As discussed above, objects may have explicitly defined 

has a signature that includes a name, parameter list, return states, and for each state, one or more legitimate predecessor 
value, and exception list. Information about a particular ^ and successor slates are specified. Furthermore, the objects, 

event is passed via the parameter specified in the event through use of events, specify actions to perform before and 

signature. The parameters may be simple values or complex after the state transition occurs. The use of rules, states and 

structures. In one embodiment, source objects package events in the type system of the present invention results in 

information into a packet that represents information com- a powerful approach to application development, namely the 
mon to all events. Additional arguments may be passed as 45 apphcation modeling approach. 

extra parameters. Event categories provide a convenient way An example of the application modeling approach may be 

to classify and organize events. illustrated through a sales order application. FIG. 4 illus- 

An object that raises an event is called a source object, and trates an example slate model for a sales order application, 

an object that receives an event is called a sink object. Thus, For the sales order application, the slate model tracks the 
the source object generates the event, and the sink object is 50 process through a complete cycle. Specifically, the slate 

the recipient or subscriber for the particular event. A request model of FIG. 4 contains a stale for each step in the sales 

event is utilized to ask permission from the sink objects. The order cycle. The slates designated in FIG. 4 are encompassed 

sink objects can either grant permission or refuse. Events, within a circle. The sales order slate model starts with the a 

known as "before" events, are fired before a specified action customer that submits an order. This is signified in the slate 
occurs. The "before" events provide sink objects an oppor- 55 model with the "Order Submitted" stale. The state model 

tunily to prepare for the event. Events, known as "after" also includes slates for "Order Approval", "Check Stock", 

events, are fired after a specified action. The after events "Print Shipping Documents", "Ship Order", "Back Order", 

give sink objects an opportunity to respond to this action. and "Archive Order." 

The "before" and "after" events may not be canceled. Jq addition to defining each slate to model the application. 

In addition to "before" and "after" events, "do" events are 60 the application developer specifies permissible slate transi- 

fired to provide sink objects an opportunity to supplement tions to define the behavior of the state model. Specifically, 

default behavior. The "do" event is called directly before the the user defines one or more slate transitions that specify the 

source object performs the action. The sink object returns a permissible paths from each predecessor state to one or more 

value that determines whether the source action should be successor slates. In the stale model example of FIG. 4, the 
done. 65 lines and arrows thai connect Ihe slates designate the legiti- 

In general, objects respond to events by calling related mate state transitions that may occur from one state to 

methods. For example, an order object may respond to a another in the sales order application. 
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For the order entry state model shown in FIG. 4, the state 

model behavior is specified such that the state model tran- TABLE 1 
sitions from the state "Check Stock" to the "Back Order" 
state only if the goods are not found to be in stock. Also, it 
is permissible to enter both the "Order Approval" state and 
the "Check Stock" state from the "Order Submitted" state, 
Furthennore, a rule, which requires approval of an order and 
printing of shipping docimients before it is shipped, is 

specified such that the "Ship Order" state is entered from a ^ , ^, 

path that includes the "Order Approved" state and the "Print ^° ^^^^ ^^If arguments required by the input 

Shipping Document" state. As illustrated by the above ^^^^[^ ^5^°"^- ^^^^ the accounts receivable "create" 

example, a real life application may be modeled to develop Tfi r'"'"'^ h^h°t kT' t ^01 amount requires 

. LLL - ^ definition such that the bill amount is equal to the order entry 

an application program based on the behavior of a state ^^^^ ^ 

IS As illustrated by the above example, state models and 

States used in the type system of the present invention are events provide a standard integration mechanism among 

defined at any point in an object by a user defined field. applications. Through use of the type system events, users 

Thus, the states are not defined in terms of derived attributes ^^^^ ^^^^^ 'o integrate a company's entire suite 

that determine their values based on the current state. of applications, if desired, even if the applications derived 

Therefore, the system does not directly perceive a signifi- from different parties. Even if an application was not devel- 

cance of being in one state rather than another, but it only ^P^.f ""^"^ " ^ /^^^ °r developer may 

,^^.T«»^,. #u« „.u*«u f %• ™ easily build a state model for the applications afterwards, by 

regulates the conditions under which a transition may occur ■ /• , , • . 

f,™ „ ♦ f ♦ ™ * . mvoKing methods and then creating event filters for inte- 

rrom a predecessor state to one or more successor states. . ... ... .. . 

grating the application with other apphcations. 

In one embodiment, stales are grouped together in com- 25 FIG. 5 illustrates state models for the example order entry 

posites for treatment as a single state. The composite state and accounts receivable applications as well as their linking 

embodiment has application for transition testing purposes. through events. The solid lines indicate the permissible state 

Grouping states into composites may be analogized to transitions, and the dashed lines indicate the events and their 

grouping graphics objects in a drawing system. The group- association with other states. Note that the functionality 

ings of objects in the drawing system permits treating, for 30 indicated by the state may be implemented in one or more 

some purposes, the graphics objects as a single group. For methods. For example, a method is called to execute the 

example, the single group of graphics objects may be moved "ship order*' function, and the calling of the "ship order*' 

together to retain relative spacing among individual objects. method triggers the event "shipped," On the receiving end. 

In one implementation, applications may, if explicidy „ f. "^1^°,^^] I"''"'"" '° ^'^""^ 

specified by an applications developer, foresee transition " t'onahty specified by th^ state. 

between states to occur even if the transition is forbidden by . As discussed above rules may be triggered as states 

conditions specified earlier by a developer. This permits ^'^^ 

foreign objects and legacy applications to be interfaced to '''^T" ^ association may be 

this system described m terms or rules. For example, a rule may be 

40 defined such that if an attribute of an object is changed, then 

The events in the type system of the present invention the action of the rule may change an attribute of a specified 

may be associated with states. Events may be associated object (e.g., the triggering of the rule invokes a set attribute 

with any entry into or exit from a state. In addition, events call to the associated object. Therefore, applications may be 

may be associated with individual paths into or out of a stale. built by specifjdng when an object fires events and by 

Events associated with stales are specified with run time 45 defining events that cause motion through a stale model. In 

triggers that cause the execution of arbitrary user specified turn, motion through the state model causes other events and 

procedures. For example, in the sales order application other methods to be invoked. 

illustrated in the stale model of FIG. 4, entry into the "Back Associations and events permit augmentation of state 

Order** state may raise an event to "notify the customer of model behavior. FIG, 6 illustrates a simplified state model 

the delay." 50 consisting of a "New Order*' state, an "Approved State'*, a 

Events may be used to link two independent applications. 71?'^ O^"*'" » 

For example, order entry and accounts receivable appUca- '° state model, a user may wish to mclude 

tions may be run as stand alone applications. These appU- 'nvoicing function that is implemented m an "Invoice 

cations may be linked through defining input and output J, ,• u ■.• .■. • l • 

events. For this example, the order entry and accounts " I^.f . J",' T T.t' f 'T'f ^ 

receivable apphcations may be Linked to interact as foUows. ''l' "bject used to implement the place order function. 

Theactionofapprovinganordergeneratesaneventtocreate :^?; p'''" TnT!?.^ T"" n- J '■'^ 

an invoice, and the action of creating an invoice generates an f'??^ ^""^^ "^'^^^ '° off a no ification 

event to print order shipping documents. The action of f^ent Dunng execution when the "Place Order state is 

shipping an order generates an event to mail the biU. and the *° to the "Filled Order state the invoice object 

actofreceivingbiUpaymentsgeneratesanevemtocIosethe ^^^ives the event notification to miplement the account 

Qjjjgj receivable functionahty. Thus, additional functionality may 

be implemented to an existing state model through use of 

To implement the preceding actions between an order events and associations, 

entry apphcation and an accounts receivable application, an 65 In addition to augmenting state models with events and 

applications developer may define the following event filters associations to provide additional functionality, slate models 

defined in Table I. may be specialized after implementation. For the example 
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order entry slate model illustrated in FIG. 6, a user may wish 
to add specialized rules that apply to a rush order, FIG. 7 
illustrates adding a rule to the order entry state model of FIG. 
6 to implement the specialized case of a rush order. This 
example includes changing the permissible slate transitions 
for a rush order. Specifically, to expedite the order entry 
process, a rush order rule permits transitioning &om the 
"New Order** stale directly to the "Place Order" slate. Table 
2 shows the rule trigger, condition, and action for imple- 



menting the rush order rule. 






TABLE 2 




Rule Trigger 


Condition 


Action 


"New Order" State 


State of Rush Order 


Call "Place Order" 


Entered 


attribute 


Method 



The rule is triggered when the "New Order" slate is 
entered. The object, which is associated with the state 
model, contains a rush order attribute. The state of the 
attribute determines whether the order is a rush order. If the 
rush order attribute indicates that the order is a rush order, 
then the action of calling both the place order method and 
the approved order method is executed. Alternatively, if the 
state of the rush order attribute indicates that this is not a 
rush order, then the normal stale flow (e.g. transitioning only 
from the "New Order" to the "Approved order" state 
occurs). Thus, a rule that governs the behavior of a stale 
model may be added without affecting the existing rules as 
well as without requiring new implementation of the state 
model. 

In one embodiment for application program development, 
the application program developer describes the structural 
nature of a class type. The developer then describes stales as 
well as the legal transitions among the states. Also, asso- 
ciations and events are used to link objects. Furthermore, 
rules may be used to specify object behavior. To support the 
events, event handlers may be written in 4GL scripting 
language. This technique allows combining state models, 
rules and handlers to implement a diagram. TTius, the 
behavior of objects, including the relationship among the 
objects, may be described, and the system will enforce this 
specified behavior at run lime. 

The type system of the present invention is dynamic. For 
example, a user may add or remove a rule which results in 
the rule immediately being enforced. In addition, a script 
may be generated that ties in additional rules for enforce- 
ment by the type system. Therefore, rules are dynamic such 
that they may be added and subsequently enforced by the 
system after a stale model has been defined. 

An Implementation of Rules In An Object Oriented 
System 

FIG. S is a block diagram illustrating program modules 
for implementing rules of the present invention. In general, 
the block diagram of FIG. 8 conceptually illustrates routine 
and methods that execute the program flow for one imple- 
mentation of rules. As shown in FIG. 8, an object interface 
300 includes a plurality of redirectors. The redirectors are 
configured as the operation (See FIG. 1). The term "redi- 
rector" refers to the operation that re-directs the program 
flow from the actual method called to the pinch-point 
operation. Typically, an object interface calls methods, 
implemented for that particular interface, through use of the 
virtual tables ("v_tables"). 

From the object interface 300, program flow is directed to 
an optimization thunk 310. In general, the optimization 
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thunk 310 implements the pinch point operation to deter- 
mine whether any rules, either before rules or after rules, 
exist for the conesponding operation. One embodiment for 
the pinch point operation follows. 

find before rules and evaluate them 
if (rules succeed) 

find override or defauU method and invoke it 
find after rules and evaluate them 

10 end if 

If no rules exist, the optimization thunk 310 calls the 
actual method (e.g., mptrQ). If any rules exist, the optimi- 
zation thunk invokes the I_Operalion 320 to invoke the 
rules identified on the before rules list 120 and/or the rules 

15 identified on the after rules list 140 (FIG. 1). For this 
embodiment, the I_Operation metaobject contains the 
Invoke method that manages the look-up and dispatch of 
instance and class level rules. The I„Operation metaobject 
also appropriately dispatches the original method. Pseudo 

20 code for implementing I_Operation is shown in block 320 
of FIG. 8. The actual method (i.e., mptro), is invoked, as 
appropriate, from I_„Operation as is illustrated by the arrows 
connecting I_Operation block 320 to the I_method blocks 
330 on FIG, 8. For this embodiment, as shown in FIG. 8, the 

25 v_tables include redirectors to an optimation thunk, which 
in turn calls l_operation. If appropriate, l_Operation 
invokes the rules, either before or after the actual method. 
The I_method, invoked from I_Operation, calls the actual 
method. After all rules and the actual method are executed, 

30 the I_Operation, through a "closure" procedure, returns to 
the caller. 

For the embodiment shown in FIG. 8, the process for 
implementing rules includes two levels: an "outer" and an 
"inner." The inner level invokes, from the method closures, 

35 the actual methods, whereas the outer level invokes, based 
on the redirector v_table or operation, the rules. Static 
v_table calls (e.g., prior compiled static code) go to the 
same location as dynamically loaded calls of the operation 
pinch point. From the callers point of view, the distinction 

40 between the outer invocation of the actual method and the 
inner invocation of the actual method is transparent. For this 
implementation, the operation evaluates rules, whereas the 
method closure strictly calls the actual method. However, in 
another embodiment, such as for deferred notifications, a 

45 method closure is implemented around the outer v_table 
member functions. In this case, the pinch point operation is 
bypassed for efiBciency or semantic reasons. Distinction 
between the outer and inner calls when implementing dif- 
ferent variations disclosed herein may help reduce spurius 

50 events, slow down, or infinite recursion. 

In one embodiment, the closures are utilized to allow 
deferred calling or continuations. In general, the closures 
maintain or hold all parameters/variajples in the current 
context (i. e., the context when the operation was called) 

55 until the later time in which the actual method is invoked. 
One embodiment for implementing a closure to support 
rules follows. 



Interface I_Closure : lunknown I Alias(Closure) 
{ 

Document 
{% 

The I_Closure interface supports deferred calling. 

It can be used to save the state of the parameters for a call 

so that the call can be invoked later from a different context. 

%] 
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Production 
{ 

FUe 
UUID 
FullNamc 
} 

typcdef ULONG VAUST ! ProtectBy(„VARARG_Visible): 
//TODO; 
marshal 

Methods 



«**imdos"; 

581AF132-BA46-11CF-BC3C-524153480003; 
"Closure Interface"; 



{ 



resolved 



index etc. 



would 



closure, 



HRESULT SctFonnfll(I_Method 'pConv, I_Operation 'pSig) 
! Document 

% SetFormal analyzes the operation's signature and caches 

information such as size, type, parameter indirection, vtable 

Should be called once to initialize the closure. 
Note: that if the closure is created from the context of a 
method 

via CreateClosure, SetFormal need not be called. The method 
already have performed the initialization. 

%}; 

HRESULT SetActualData( 
I_Array* ParamArray 
! Document {% The parameters for this 

method. %}, 

lunlcnown •Object !(in, iid_is(rIID)) 
! Document {% The object on which this 
method is a member.%}, 

REFIID rllD 

) 

! Document 

% SetActualData copies data from the array of I__Data into the 
where it is held until Invoke is called. 

%}; 

HRESULT SetActual(IUnknown •Object, VALIST Parameters) 
! Document 

{% copies data from the va_list into the closure. 
Its separate from Invoke to allow holding data for deferred 
calls. 

HRESULT Invoke 0 
! Document 

{% Invoke makes the call using the information cached by 

SetFormal 

and SctAaual 

%}; 

HRESULT GctActualData(l_Data ••pRet, I_Array 'pArg) 
! Document 

{% GctActualData retrieves the actual parameters from the 
closure and 

places them into the array of I_Data. 

Used to retrieve the outbound parameters after Invoke is 

called. 

%}; 

HRESULT GetActual(VAUST Parameters) 
! Document 

{% Copies data from the closure into the va_list. 
Used to retrieve the outbound parameters after Invoke is 
called. 



} 



} 
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In one embodiment, the pinch point operation is executed 
with a thunk. In general, a thunk is compiler generated code 
executed between the callers code and the calling code. 
Typically, thunks in the prior art have been utilized to 
convert calling conventions between the caller code and the 
calling code. For efficiency reasons, in one embodiment, the 
thunk is generated in assembly level code so as to minimize 
the execution time. For the rules implementation, for each 
call to a method, the redirector in the object interface 
redirects the call to the ihunk routine. This process is 



executed even if no additional rules are added to the called 
method. Accordingly, if the "checking" routine, which deter- 
mines whether any overrides or rules exist, is inefficient, the 
overall performance of the software may be substantially 
degraded. Thus, in the preferred embodiment, the "check- 
ing" routine is implemented with extremely efficient assem- 
bly language level code. 

FIG. 9 is a block diagram illustrating a plurality of bit 
maps for use with one embodiment of the optimization 
thunk. For this embodiment, a type level bit map 400 
identifies whether any override or rule exists for the corre- 
sponding object, on the type or class level. The type level bit 
map 400 may be implemented with a single bit for each 
object that indicates whether a method or override exists. In 
one embodiment, the bit maps are 32 bits in length to permit 
checking of bits in a single operation. As is well known in 
object oriented programming, each object may be identified 
through a global unique identifier ("GUID"). 

The bit maps of FIG. 9 further include, to implement rules 
on a per instance basis, an object instance bit map 410. As 
20 shown by the line and arrow on FIG. 9 that connects object^ 
in the type level bit map 400 to the object j instance bit map 
410, each object includes an object instance bit map 410. For 
simplicity, only one such object instance bit map 410 is 
shown in FIG. 9. In general, the object instance bit map 410 
identifies, for the corresponding object, whether the specific 
instance includes method overrides or rules. The object 
instance bit map 410 is implemented with a single bit for 
each object instance (e.g., instanccj, instanccj, instancca, . . . 
instance J. 

For each object instance in the object instance bit map 
410, a corresponding instance method bit map 420 exists. 
The instance method bit map 420 indicates whether a 
specific method, on the corresponding object instance, 
includes any method overrides or rules. The bit maps 
illustrated in FIG. 9 provide information, on a per type level 
and instance level, to identify methods with rules, by simply 
examining a single bit for each bit map. The thunk 
implementation, which only checks a single bit initially, 
requires very little program overhead. In contrast, checking 
for rules by calling the corresponding method would result 
in a significant amount of overhead that would reduce the 
efficiency and performance of the software. Because the 
thunk is generated by the compiler, the user, implementing 
rules on methods, is not required to program code to check 
each method called for rules. 

FIG. 10 is a flow diagram illustrating one embodiment for 
implementing rules. When a method is called, a determina- 
tion is made as to whether any rules associated with the class 
type of the method called exists, as shown in blocks 500 and 
510. If no rules are associated on the class level, a deter- 
mination is made as to whether any rules are associated on 
the instance level, for the particular instance of the method 
called as shown in block 520. As shown in block 530, if any 
rules are associated with the class of the method called, 
either on the type level or instance level, then a determina- 
tion is made as to whether the method called has any 
associated rules. If so, the before rules list is checked, and 
any such before rules are executed as shown in blocks 540 
and 550. As shown in block 560, the actual method is called. 
If any after rules exist, the after rules are executed as shown 
in blocks 570 and 580. If no rules are associated with the 
object, on either the class or the instance level, then the 
actual method is called as shown in block 590, 

^5 Object Oriented Development Environment 

FIG. 11 is a block diagram illustrating an object oriented 
development environment that incorporates the techniques 
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of the present invention. An object mediator 605 permits compiled (e.g., a C++ compiled class). FIG. 12 is a flow 
users of the object oriented development environment create diagram illustrating one embodiment for installing a rule. As 
new object types, edit object types as well as to instantiate shown in block 710, the object oriented development en vi- 
and manipulate objects from the object types. The object ronment provides a means for selecting an object to aher. 
mediator 605 operates in conjunction with any number of 5 The developer, through a prompt, defines the rule as a 
program development tools, such as CASE tools, and appli- "before rule" or an "after rule" as shown in block 720. As 
cation programs, such as a form building program. The shown in block 725, the developer enters the declarative 
program development tools and application programs arc rule. To commit the rule, the user enters an indication (i.e., 
illustrated by the development tools/applications block 616. double clicks on a commit box within a dialog box). In 
The development took/applications programs 616 includes lo response to committing the rule, if the rule is an after rule, 
fourth generation language (4GL) capability, that permits then the rule is added to the after rule list for the corre- 
the user to generate scripts for execution in conjunction with spending class/instance/method as shown in blocks 740 and 
compiled 3GL classes and declarative rules and events. 750. If the rule is a before rule, then the rule is added to the 
For this embodiment, the object mediator 605 accesses before rule list for the class/instance/method as shown in 
metadata 680, including object interfaces 640, rules 610, is blocks 760 and 765. In addition, the bit flags for the 
events 630, and abstract specifications (type system) 675. In type/instance/methods are set as shown in block 770. 
general, the object mediator 605 permits a user to instantiate -phe foUowing example code adds and deletes rules from 
objects based on the type system 675. The object mediator the object oriented software environment. 
605 is intended to represent a layer of software that permits 
a user to manipulate the metadata for use in programming 20 

development. For example, the object mediator 605 may 

support a C++ programming platform. The object mediator interface [_Object and i_AbstractDataType 

605 executes those functions typically found in an object ^ . , „ , « , . . ^ ^ 

, J , , , . . ■ 1 J- u .1- HRESULT AddlRulcBcncfactor(I_InhcritablcT\'pe ■ pBencfactor) 

oriented development environment, mcluding, but not hm- , Document {% 

ited to, creating new object types, editing object types as 25 AddRulcBcnefactor notifies this object that pBenefactor has 

well as instantiating objects from the object types and in fact inheritable rules for this type. This could turn out to be a pointer 

object mediator 605 is intended to represent a broad class of °^J«^^'« ^yP/* ^ the immediate type doesn't have 

■' * !iTi\j mine it UfmilH ruffr Hir*>r»Mif trt thf nrct ci inprt irrw> u/nifh 

software that performs these functions. 



any rules it would refer directly Lo the first supertype which has rules. 



As shown in FIG. 11, the object oriented development HRESULT RemoveRuleBenefactorCUnheritablelVpe • 

environment also includes an object store 660. In general, ^^D(^ment (% 

the object store 660 stores object instances defined by the RemoveRul^nefactor removes an UlnheritablelVpe that no longer has 

abstract specification (type system ) 675 (i.e., object rules for this object, 
instances persist in the object store 660). For example, the 

object store 660 may comprise an object oriented database result HasRuies(OMRuieTriggerType trigger, [.Member • 

1 i- 1 ^ f K 35 Member 

or a relational aataoase. , Document {% The specific member being evaluated. For high level 

The object oriented development environment 600 further f"les pertaining 

includes a graphical user interface (GUI) 670 that permits a '° ^Yi^!'^^ •^tiUeT'"'''' ""'^ ^' 
user to interface with the object oriented software develop- j^^) 

ment environment. In one embodiment, the GUI 670 \ Document {% Receives an iterator if the object has rules that are 

displays, on an output display of a computer, a dialog box to evaluated in 

permit a user of the system to input parameters that specify ^^^P°.^^ u"^^'"" .ttti t ^1 

^ . , r™ 1111 111. t J identified by tngger, otherwise returns NULL. %} 

rules and events. The user may both add and delete rules and i_inheritabieType - NextSource 

events from objects. Also shown in FIG. 11, for this !(out) 

embodiment, the GUI 670 transfers the rule/event parameter ! Document {% Receives an LtnheritablelVpe if the object's type 

information to the rules/event installation module 677. In furthw rales 

general, the rules/event instaUation module 677 installs rules t^al might be evaluated in response to any of the rule triggers identified 

610 and events 630 that correspond with types and/or by 

instances of the system. In one embodiment, the rules/events trigger, 

. 11 J 1 ^™ • . , r> n otherwise returns NULL. You need to call NextSource *s FmdRule method 

mstallation module 677 comprises, in part, a Basic Program- ^ ^^^^^ 

ming Language Compiler. For this embodiment, the Basic exhaustive search for rales. %} 

Programming Language Compiler receives rules and events, ) 

expressed in the Basic Programming Language, and com- ' (Virtual) . . 

piles the code for execution by the system The ntleVevents ' '^T::.tZl^rnrii::Xn^"l^^^^^ idco.mcd 

installation module also updates the list of rules 610 and the by 

list of events 630, as described below in conjunction with a trigger. You can pass a list of trigger types as trigger with each trigger 

description of FIG. 12. »yi« separated 

by tilc logical OR symbol. The iterator may be used to find the specific 

The object oriented software development environment OMRuieTriggerTypes 

600 further includes an interface definition language (IDL) which trigger the evaluation of the object's rules. For example, if you pass 

compiler 620 that generates the object interfaces 640 and the MmleTriggciTVpc values as trigger and result is true, the object's 

thunk 310. As described above, the object interfaces 640 ^lu^^d^iL'^s 
include "re-directors" to execute the thunk 310 in response 

to the calling of a method supported by an object interface l_Collection *■ l_Object:;Rules 

640. As shown in FIG. 6, the thunk 310 is also generated by ^ 

the IDL compiler 620. ^5 ^""Y^"^ ^-^odeUnit : lunknown 

The rules of the present invention permit augmenting a Document 
method with rules even though the method is already 



evaluated in response to 1,2, or all 3 of the OMRulcTriggeriype triggers. 
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•cootinued 



The Lntcr&ice I_CodeUait manages one compilation unit of source 

code. 

A compilation unit is a group of snippets of source code. 
Usually they correspond to all the overides for a class by one 
language. 

%) 

Attributes 
{ 

I_AbstractDataTypeComp * Contextiypc ! Association 

(UnitContext) 

! Document 

{% Context this code unit should be compiled within. 

%}; 

I_ConectioD • Methods // I_Collection<r_Method *> 
! (Read) 

! Association (McthodlbUmt) 
! Document 

{% Snippets returns a collection of the methods in this 
compilation unit. 

%}; 

I_ErrorMgr * Errors 
! (Read) 
! Document 
{% Errors returns a list of syntax enors. 

%}; 

BOOL Dirty 
! Document 

{% Dirty returns TRUE if any snippet has been changed; 
otherwise, it returns FALSE. 

%}; 

QUID Language 
! Document 

{% Language identifies the language interpreter for this unit. 

\+ 
par 

\par 

ReadAvritc attribute. 
%}; 

INT Unitid 
! (Read) 
! Document 

{% Unitid is used internally to identify the unit. \par 
^r 

Read-only attribute. 
%}: 

}; 



Integration of Three Styles of Programming 

The type system of the present invention supports inte- 
gration of three styles of application program development 
in an object oriented environment. In one approach, the type 
system supports the use of a declarative approach to appli- 
cation program development. For the declarative approach, 
a user specifies the functional operation of the application 
program. In one embodiment, the user specifies the func- 
tional operation of the application program through use of 
rules and events, as described above. The declarations are 
enforced by the type system. Thus, the user is not required 
to write code to enforce the declarations. 

The type system also supports a third generation lan- 
guages (3GL) compiled approach to applications program 
development. For the 3GL compiled approach, the user 
develops classes, through use of languages such as C++ and 
Pascal, to implement the application program. The code is 
then compiled for run time operation. The 3GL compiled 
approach to application program develop provides a pow- 
erful tool for implementing a wide range of functionality for 
the program. In one embodiment, the 3GL compiled 
approach is developed through use of an extended interface 
definition language (EIDL). The EIDL permits a user to 
define types in accordance with the extended type system of 
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the present invention. The EIDL code is then compiled, 
through use of an EIDL compiler, for run time operation in 
the object oriented environment. 
The object oriented development environment of the 

5 present invention ftirther supports applications development 
through use of fourth generation language (4GL) scripting. 
As will be appreciated by one skilled in the art, the integra- 
tion of the declarative, the 3GL compiled and the 4GL 
scripting approaches provides the greatest flexibility and 

50 power to develop application programs. For example, a 
declarative approach to application program development 
provides a good way to add features or functionality that is 
not part of the original system. However, traditional declara- 
tive systems have limitations such that some objectives 

15 cannot be expressed in a declarative manner Therefore, 
integrating the declarative, 3GL compiled and 4GL scripting 
approaches provides the application program developer the 
ability to select a style that most suits the particular needs for 
a given problem. 

20 

Computer System 

FIG. 13 illustrates a high level block diagram of a general 
purpose computer system in which the object oriented 

25 development system of the present invention may be imple- 
mented. A computer system 1000 contains a processor unit 
1005, main memory 1010, and an interconnect bus 1025. 
The processor unit 1005 may contain a single 
microprocessor, or may contain a plurality of microproces- 
sors for configuring the computer system 1000 as a multi- 
processor system. The main memory 1010 stores, in part, 
instructions and data for execution by the processor unit 
1005. The main memory 1010 stores the executable code of 
the object oriented development system when in operation. 

25 The main memory 1010 may include banks of dynamic 
random access memory (DRAM) as well as high speed 
cache memory. 

The computer system 1000 further includes a mass stor- 
age device 1020, peripheral device(s) 1030, portable storage 

40 medium drive(s) 1040, input control device(s) 1070, a 
graphics subsystem 1050, and an output display 1060. For 
purposes of simplicity, all components in the computer 
system 1000 are shown in FIG. 13 as being connected via the 
bus 1025. However, the computer system 1000 may be 

45 connected through one or more data transport means. For 
example, the processor unit 1005 and the main memory 
1010 may be connected via a local microprocessor bus, and 
the mass storage device 1020, peripheral device(s) 1030, 
portable storage medium drive(s) 1040, graphics subsystem 

50 1050 may be connected via one or more input/output (1/0) 
busses. The mass storage device 1020, which may be 
implemented with a magnetic disk drive or an optical disk 
drive, is a non-volatile storage device for storing data and 
instructions for use by the processor unit 1005. In the 

55 software embodiment, the mass storage device 1020 stores 
the object oriented development system software for loading 
to the main memory 1010. 

The portable storage medium drive 1040 operates in 
conjunction with a portable non-volatile storage medium, 

60 such as a floppy disk or a compact disc read only memory 
(CD-ROM), to input and output data and code to and from 
the computer system 1000. In one embodiment, the object 
oriented development system software is stored on such a 
portable medium, and is input to the computer system 1000 

65 via the portable storage medium drive 1040. llie peripheral 
device(s) 1030 may include any type of computer support 
device, such as an input/output (I/O) interface, to add 
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additional functionality to the computer system 1000. For 
example, the peripheral device(s) 1030 may include a net- 
work interface card for interfacing the computer system 
1000 to a network. The object oriented development system 
software may be input to the computer system 1000 via a 
portable storage medium or a network. 

The input control device(s) 1070 provide a portion of the 
user interface for a user of the computer system 1000. The 
input control device(s) 1070 may include an alphanumeric 
keypad for inputting alphanumeric and other key 
information, a cursor control device, such as a mouse, a 
trackball, stylus, or cursor direction keys. In order to display 
textual and graphical information, the computer system 
1000 contains the graphics subsystem 1050 and the output 
display 1060. The output display 1060 may include a 
cathode ray tube (CRT) display or liquid crystal display 
(LCD). The graphics subsystem 1050 receives textual and 
graphical information, and processes the information for 
output to the output display 1060, The components con- 
tained in the computer system 1000 are those typically found 
in general purpose computer systems, and in fact, these 
components are intended to represent a broad category of 
such computer components that are well known in the art. 

The object oriented development system may be imple- 
mented in either hardware or software. For the software 
implementation, the object oriented development system is 
software that includes a plurality of computer executable 
instructions for implementation on a general purpose com- 
puter system. Prior to loading into a general purpose com- 
puter system, the object oriented development system soft- 
ware may reside as encoded information on a computer 
readable medium, such as a magnetic floppy disk, magnetic 
tape, and compact disc read only memory (CD-ROM). In 
one hardware implementation, the object oriented develop- 
ment system may comprise a dedicated processor including 
processor instructions for performing the functions 
described herein. Circuits may also be developed to perform 
the functions described herein. 

Although the present invention has been described in 40 
terms of specific exemplary embodiments, it will be appre- 
ciated that various modifications and alterations might be 
made by those skilled in the art without departing from the 
spirit and scope of the invention. 

What is claimed is: 

1. A method for customizing functionality of an object in 
an object oriented software system, said method comprising 
the steps of: 

receiving an identification of at least one compiled object, 
wherein said compiled object comprises at least one 
method; 

receiving one or more declarative statements to augment 
the functionality of said method of said compiled 
object, wherein a declarative statement comprises a 
constraint or requirement generally associated with 
said method of said compiled object; 

generating a dynamic association between said one or 
more declarative statements and said method identified 
on said compiled object, wherein said dynamic asso- 
ciation links said declarative statements to said method 
on said compiled object without re -compiling said 
object; and 

executing said declarative statements such that when said 
method on said object is called, said one or more 
declarative statements, associated with said method, 
are executed in addition to said method. 
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2. The method as set forth in claim 1, wherein the step of 
generating a dynamic association between said one or more 
declarative statements and said method comprises the step of 
associating a rule to said method. 

3. The method as set forth in claim 2, wherein the step of 
associating a rule to said method comprises the step of 
associating a rule to execute before execution of said 
method. 

4. The method as set forth in claim 2, wherein the step of 
associating a rule to said method comprises the step of 
associating a rule to execute after execution of said method. 

5. The method as set forth in claim 1, wherein the step of 
generating a dynamic association between said one or more 
declarative statements a method on an object comprises the 
step of associating one or more declarative statements to a 
method on a specific instance of said object. 

6. The method as set forth in claim 1, wherein the step of 
generating a dynamic association between said one or more 
declarative statements a method on an object comprises the 
step of associating one or more declarative statements to a 
method on a type level that defines said object. 

7. The method as set forth in claim 1, wherein the step of 
generating a dynamic association between said one or more 
declarative statements and said method comprises the steps 
of: 

associating said method to a second method; and 
generating an event to fire from said method to said 
second method. 

8. The method as set forth in claim 1, wherein the step of 
associating one or more declarative statements to a method 
on an object comprises the steps of: 

redirecting said call to said method to a pinch-point 
operation; 

determining, in said pinch-point operation, whether any 
declarative statements are associated with said method 
called; and 

executing said one or declarative statements when any 
declarative statements are associated with said method 
called. 

9. The method as set forth in claim 8, wherein said the step 
of redirecting said call to said method to a pinch-point 
operation comprises the step of redirecting said call to said 
method in an interface for said object that exposes said 
method. 

10. The method as set forth in claim 8, wherein said pinch 
point operation comprises an optimization thunk imple- 
mented in assembly language. 

11. A method for customizing functionality of objects in 
an object oriented environment, said method comprising the 
steps of: 

storing a plurality of objects, each object comprising at 
least one method and an interface, said interface com- 
prising a redirector; 

storing a pinch-point operation; 

receiving one or more declarative statements to augment 
the functionality of said method of said object; 

receiving a call, via said interface, to execute said method; 

redirecting, said call from said method to said pinch-point 
operation; determining, from said pinch-point 
operation, whether said method on said object includes 
one or more declarative statements associated with said 
method; and 

executing said one or more declarative statements if said 
declarative statements are associated with said method. 
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12. A method for customizing fuoctionality of objects in 
an object oriented environment, said method comprising the 
steps of: 

storing a repository of compiled objects, wherein a com- 
piled object comprises at least one method and said 
compiled objects being defined by one or more object 
type systems; 

providing to a user a means to specify one or more 
declarative statements; 

dynamicaUy associating said one or more declarative 
statements to at least one method of an object, wherein 
said dynamic association links said one or more 
declarative statements to said method on said compiled 
object without re-compiling said object so as to 
re-direct calls from said method to said declarative 
statements; and 

executing said one or more declarative statements when 
said method on said object is called. 

13. A method for integrating declarative, compiled and 
scripting approaches for developing application programs in 
an object oriented environment, the method comprising the 
steps of: 

implementing an abstract specification for an extended 
definition type system that comprises members to 
enforce rules through the type system; 

receiving declarative rules to implement functionality for 
application program development by adding one or 
more declarative rules to at least one method; 

dynamically associating said declarative rules to at least 
one method of an object, wherein said dynamic asso- 
ciation links said one or more declarative statements to 
said method on said compiled object without 
re -compiling said object so as to re-direct calls from 
said method to said declarative statements; 

enforcing the declarative rules as rules in the type system; 

receiving complied code developed from an object- 
oriented language and compiled to include the extended 
definitions for the type system, wherein the code com- 
prises a pluraHty of types; 

providing access to the types of the compiled code for 
application development; 

receiving scripts developed from a four generation lan- 
guage (4GL) to specify functionality for application 
program development; and 

enforcing the scripts as rules in the type system. 
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14. A computer readable medium comprising a plurality 
of instructions, which when executed by a computer, causes 
the computer to perform the steps of: 

receiving an identification of at least one compiled object, 
wherein said compiled object comprises at least one 
method; 

receiving one or more declarative statement to augment 
the functionality of said method of said compiled 
object, wherein a declarative statement comprises a 
constraint or requirement generally associated with 
said method of said compiled object; 

generating a dynamic association between said one or 
more declarative statements and said method identified 
on said compiled object, wherein said dynamic asso- 
ciation links said declarative statements to said method 
on said compiled object without re-compiling said 
object; and 

executing said declarative statements such that when said 
method on said object is called, said one or more 
declarative statements, associated with said method, 
are executed in addition to said method. 

15. The computer readable medium of claim 14, wherein: 
the step of generating a dynamic association between said 

one or more declarative statements and said method 
identified on said compiled object comprises the step of 
generating redirectors, on an interface exposing said 
object, to redirect a method call to a pinch-point 
operation; and 
the step of executing said declarative statements com- 
prises the step of executing said pinch-point operation 
to determine if any declarative statements are linked to 
said method. 

16. The computer readable medium of claim 14, wherein 
the step of generating a dynamic association between said 
one or more declarative statements and said method com- 
prises the step of generating a dynamic association between 
one or more declarative statements to a method on a specific 
instance of said object. 

17. The computer readable medium of claim 14, wherein 
the step of generating a dynamic association between said 
one or more declarative statements and said method com- 
prises the step of generating a dynamic association between 
one or more declarative statements to a method on a type 
level that defines said object. 
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